Fix what only worked on Linux, and a CRLF level file bug - #21

A level file written on Windows does not load anywhere else. Its lines end with
a carriage return before the line feed, and only Windows takes that back off
when reading, so everywhere else the carriage return stays at the end of the
line. There it makes the last value on the line, or a section marker standing
alone, into something the parser does not recognise, and loading fails outright:
verified here by converting a level to CRLF, which turns into "The level file
can't be loaded". Helper::readFile now strips it, which covers every level and
every config file since they all come through there. The same level loads
cleanly afterwards, as do all twelve config files converted the same way.

Then the Windows specific parts:

The window icon is installed with SetClassLong and a handle cast to LONG. A
handle is 64 bits wide in a 64 bit build and LONG stays 32, so that does not
compile there. SetClassLongPtr is the same call in a 32 bit build.

The Discord link ran xdg-open, which is the freedesktop way and exists on
neither of the other two. It now uses ShellExecute on Windows and open on macOS.

The editor's file lists asked whether a name starts with a dot to decide whether
a file is hidden. On Windows that is an attribute of the file rather than
anything in its name, and the code that would have read it was commented out, so
the "show hidden files" checkbox did nothing. It now reads the attribute, which
needs the whole path rather than the file name.

setupOgreResources treated a path as absolute if it starts with '/', which no
absolute Windows path does. And the two places that make sure a folder ends with
a separator only accepted '/', so a path ending in a backslash got a slash added
after it.

Only the level file fix is verified: it is the only one of these that can be
reached from Linux.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
(cherry picked from commit f45b427)

MinGW's libstdc++ already defines NOMINMAX, so defining it again warns,
and the game compiles with warnings treated as errors by default. Only
define NOMINMAX and WIN32_LEAN_AND_MEAN when nothing else has.

With this, every game translation unit compiles for Windows: checked
with MinGW-w64 GCC (x86_64 and i686) against real Windows headers,
Ogre 13.6.5, CEGUI and SFML 2.6.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

On Apple the data path came only from the bundle layout, and nothing at
all set the plugins.cfg path: outside a real .app bundle the game could
not find its data and never loaded a render system. The current-folder
overrides (data and plugins.cfg in "." win over the installed ones)
and the plugins.cfg resolution were sitting in the Windows-and-Linux
branch even though they are not platform specific; run them on every
platform.

Verified on macOS: the game now starts, loads all its data and runs a
level in --server mode. (Graphics could not be exercised on the build
machine, a VM with no GL driver; the rendering path is unchanged and
assumes working drivers.)

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>